The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
A network monitoring system (NMS) is a system that constantly monitors a computer network for slow or failing components and that notifies a network administrator (via email, pager or other alarms) in case of outages. An NMS monitors the network for problems caused by overloaded and/or crashed servers, network connections or other devices. For example, to determine the status of a webserver, monitoring software may periodically send Hypertext Transfer Protocol (HTTP) request to fetch a page. To determine the status of an email server, monitoring software may send a test message through Simple Mail Transfer Protocol (SMTP).
Metrics that an NMS commonly measures include server response time, server availability, server uptime, consistency, and reliability. Status request failures usually produce an action from the monitoring system. These actions vary. An alarm may be sent (via Short Message Service (SMS), email, etc.) to the resident system administrator, and/or automatic failover systems may be activated to remove a troubled server from duty until that server can be repaired.
An NMS may use an SNMP polling-based mechanism extensively for collecting large amounts of inventory, configuration, and performance data for a network-connected device. In typical SNMP use, one or more administrative computers called managers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system executes, at all times, a software component called an agent which reports information via SNMP to the manager.
Essentially, SNMP agents expose management data on the managed systems as variables. The protocol also permits active management tasks, such as modifying and applying a new configuration through remote modification of these variables. The variables accessible via SNMP are organized in hierarchies. These hierarchies, and other metadata (such as type and description of the variable), are described by management information bases (MIBs).
An SNMP-managed network consists of three key components: a managed device; an agent, which includes software which runs on the managed device; and the NMS, which is software that runs on the manager. A managed device is a network node that implements an SNMP interface that allows unidirectional (read-only) or bidirectional access to node-specific information. Managed devices exchange node-specific information with the NMS. Sometimes called network elements, the managed devices can be any type of device, including, but not limited to, routers, access servers, switches, bridges, hubs, Internet Protocol (IP) telephones, IP video cameras, computer hosts, and printers. An agent is a network management software module that resides on a managed device. An agent has local knowledge of management information and translates that information to or from an SNMP specific form. The NMS executes applications that monitor and control managed devices. An NMS provides the bulk of the processing and memory resources required for network management.
As is mentioned above, an NMS may use a polling-based mechanism to collect inventory, configuration, and performance data for a managed device. The polling interval depends on the type of data being collected. Inventory and configuration data are typically collected less frequently than performance data are. As is mentioned above, SNMP may be used to modify a managed device's configuration through modifying variables in the managed device's MIB. The MIB is a virtual database. Objects in the MIB are defined using a subset of Abstract Syntax Notation One (ASN.1). The database is hierarchical (tree-structured). Entries in the database are addressed through object identifiers (OIDs).
Sometimes, the interval of collection of OIDs through periodic polling can be as high as once every minute. In many cases, the quantity of OIDs to be collected is in the order of thousands. This burdens the network and the devices being polled. For example, it can take up to 100 Kbps of bandwidth to query 40 OIDs. Thus, many management applications typically schedule inventory collection only for times of day when the network usage is very low (e.g., at midnight). This burden on the network and the polled devices becomes exacerbated when there are error conditions such as SNMP timeouts.
The inventory and configuration related OIDs are collected typically for two purposes: change detection and profiling. Change detection involves identifying whether anything in the network has changed, thus identifying the effect of such changes in the network. Profiling involves keeping the inventory and configuration of the network and devices synchronized for the purpose of generating a current profile of managed devices and the network as a whole.
In cases of audits, SNMP polling is even more intensive. A data collection engine involved in performing an audit needs to be very robust. In these cases, the task of polling an entire set of managed objects is highly inefficient, further compounding network and device woes.
In many scenarios, such as in audits, performance monitoring, and optimization, there is a need to identify changes in the managed objects that are being monitored. The changes are typically detected at the NMS level by polling the managed objects and comparing the previously polled OID values with the newly polled present OID values. However, this underlying paradigm of change detection at the NMS level itself is very inefficient since it requires all the managed objects to be polled and then compared with the previous values. Present techniques for change detection are highly inefficient and too burdensome on managed devices and the networks to which those devices are connected.